	Nous avons aussi testé notre application dans le cadre d'un programme qui calcule la somme des éléments d'un tableau. Voici les graphiques de résultats. L'axe des absices correspond au nombre d'éléments dans le tableau, l'ordonnée au temps en millisecondes pour effectuer la somme de ces éléments.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{img/perf3.png}
		\caption{Comparatif du temps d'exécution pour la somme d'élément d'un tableau}
	\end{figure}
	
	Dans cette situation, la version séquentielle du code est plus rapide sur les tableaux de petite taille. La version \textit{pthread} est plus lente toujours à cause des changements de contextes en espace noyau.\\
	
	 Nous pouvons tout de m\^eme constater que sur des tableaux de grande taille, notre bibliothèque arrive à \^etre plus rapide que du code séquentiel. Or comme notre code effectue de nombreux changement de contexte et que cela devrait le ralentir, nous avons émis l'hypothèse que cette accélération "anormale" peut \^etre due au nombre de thread créés. En effet, l'ordonnanceur du système d'exploitation doit intervenir et donner la main plus régulièrement à nos threads utilisateur ce qui expliquerait ce comportement.
	
	